feat(parameters): parameter conversion - #688

A parameter's conversion was reachable only through trait resolution.
ParameterVariant supplied the kind and both directions, and every read,
write and declaration went through the type. That shut out any type whose
crate does not own the trait: std::time::Duration cannot implement
ParameterVariant, and neither can a chrono or uom type, so configuring
one meant a newtype in the caller's crate that existed for no other
reason.

Move the conversion into a value. ParameterConversion holds the kind and
the two directions, a declaration fixes one, and every handle it produces
carries it. ParameterConversion::of_variant assembles one from what a
ParameterVariant already states, so a type that has an implementation
needs nothing further and declares exactly as before. The trait keeps
stating its kind and its conversions and does not also hand out an
assembled conversion, so there is no second way to say the same thing and
no way for the two to disagree. The orphan rules do not apply to values,
so declare_parameter_with takes a foreign type directly.

The conversion back from a parameter value is fallible, because that
value arrives from a parameter file or from a remote SetParameters call
and cannot be assumed representable. The constructors take the shapes
std's own functions already have, so a duration in seconds is
ParameterConversion::double(Duration::as_secs_f64,
Duration::try_from_secs_f64) with nothing written by hand.

get_with and set_with give the undeclared parameter API the same reach,
so a parameter whose type has no implementation is readable and writable
there too.

The handles' Debug implementations lose their ParameterVariant bound,
which was only ever needed for the conversion they now hold.

The range setter splits in two. range() keeps resolving to the parameter
type's own Range and moves to an impl block that still requires
ParameterVariant, so bounds stay in the units the parameter is read back
in and a literal that does not fit is still a compile error.
stored_ranges() takes the erased form, in the terms the conversion stores
the value in, for a parameter whose type has no Range to name. Two names
because the blocks overlap and one name would be a duplicate definition.

No existing test changed, which is what says the default conversion is
the one the types already described for themselves.

Assisted-by: Claude:claude-opus-5 [Claude Code]

A ParameterKind does not uniquely identify a Rust type. Several types can
share one, and a value of the right kind can still be unrepresentable in
the type a parameter was declared with. validate_parameter_setting only
compared kind discriminants and Parameters::set only compared kinds,
while every getter assumes the stored value converts back:

    self.conversion.from_value(..).ok().unwrap()

So a remote SetParameters call could store a value that passes validation
and then panic the node on the next read. This is reachable today by
anyone implementing the public ParameterVariant trait for a type whose
conversion from ParameterValue is partial, and becomes unavoidable once
narrow integer and enum parameter types exist.

Run the declaration's conversion on both write paths, before the range
check and before the custom validate callback, whose type-erasure wrapper
depends on the value being convertible. The check is the conversion the
declaration already carries, so there is nothing extra for a type to
implement and no way for it to accept a value that a later read would
then reject. ParameterValueError::Invalid carries the reason the
conversion gave back to the caller, which the parameter service puts in
the response so the operator who made the call can see why the value was
refused.

Assisted-by: Claude:claude-opus-5 [Claude Code]